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INTRODUCTION 

This  paper  discusses  the  need  for  a mechanism  that  allows 
various  views  of  product  data  to  interface  with  various 
techniques  for  managing  product  data.  The  Information  Resource 
Dictionary  System  (IRDS)  [ANSI  Standard  X3. 138-1988]  is  proposed 
as  an  integration  and  configuration  management  mechanism  for  the 
Product  Data  Exchange  Specification  (PDES) . 


BACKGROUND 

The  design  of  manufacturable  products  is  an  increasingly 
complex  process  for  industry.  Advances  in  technology  have 
resulted  in  compartmentalized  life-cycle  product  development 
activities.  This  has  led  to  the  isolation  of  the  product 
designer  from  others  participating  in  product  development.  Those 
isolated  from  access  to  the  designer  are:  (a)  the  sponsor  who  has 
the  need  for  the  product,  (b)  the  process  planner  who  understands 
how  the  product  can  be  produced  in  the  factory,  (c)  the 
manufacturing  manager  who  understands  the  operation  and 
performance  of  the  shop  floor  equipment,  (d)  the  quality 
assurance  inspector  who  understands  how  to  measure  the 
functionality  of  the  product,  (e)  the  service  engineer  who  is 
responsible  for  repair  and  preventive  maintenance  of  the  product, 
and  (f)  the  reliability  engineer  who  is  responsible  for  tracking 
the  performance  of  the  product  over  its  lifetime. 

At  each  stage  of  the  life-cycle,  important  knowledge  about 
the  product  is  acquired.  Unfortunately,  this  information  is 
seldom  available  to  staff  working  on  other  stages  of  product 
development.  Specifically,  the  designer  may  not  understand  the 
impact  of  his  design  on  the  creation  of  a true  ’world-class' 
product  — one  built  to  minimum  cost  with  highest  quality  and 
greatest  functionality,  in  the  shortest  time  span.  To  integrate 
the  isolated  activities  of  product  development,  more  attention 
needs  to  be  paid  to  the  information  exchange  that  occurs  during 
the  product  life-cycle. 

With  sophisticated  and  ever  evolving  technologies,  users  of 
product  data  are  faced  with  the  need  to  exchange  information 
across  diverse  and  dissimilar  systems.  At  the  same  time,  these 
users  must  maintain  the  various  contexts  within  their  organiza- 
tion and  functional  responsibility.  ~ The  - integration'  of  systems 
as  well  as  the  integration  of  information  within  this  technologi- 
cal heterogeneity  is  the  "core"  of  the  developing  Product  Data 
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Exchange  Specification  (PDES) . Recognition  of  the  need  to 
organize  the  integration  and  exchange  of  this  information  has 
resulted  in  a major  effort  within  the  PDES  community  to  define  an 
architecture  for  this  purpose. 


TOPICAL  MODELS 

The  PDES  community  has  been  seeking  solutions  to  manage  and 
exchange  information  about  products  as  opposed  to  the  graphical 
exchange  of  drawings  of  products.  The  IGES/PDES  Organization, 
the  voluntary  standards  organization,  has  been  developing  the 
product  information  descriptions  (called  conceptual  models) 
across  a broad  industrial  base  (e.g.  mechanical,  electrical, 
etc.).  These  descriptions,  some  common  to  many  industries  and 
some  unique  to  particular  industries,  form  a "core  of 
information"  about  products.  As  application  activities  are 
defined,  committees  have  been  formed  to  formalize  the  necessary 
information  shared  between  product  development  activities.  This 
effort  has  resulted  in  conceptual  models  which  provide  the 
framework  for  the  product  information  to  be  exchanged. 

When  a consensus  has  been  reached  on  an  individual  topical 
model,  the  model  is  then  voted  out  of  committee  as  a draft 
specification.  The  various  models  have  then  been  considered  for 
integration,  when  they  contain  common  information.  The  PDES 
Integration  Committee  was  formed  to  find  the  overlaps  and 
intersections  between  different  applications.  Identification  of 
the  integration  elements  needed  to  connect  individual  application 
models  has  resulted  in  a "core"  model  called  the  Integrated 
Product  Data  Model  (IPDM) . This  model  is  used  to  describe  how 
the  topical  models  can  be  merged  into  the  complete  PDES 
conceptual  model. 

The  urgency  to  produce  a PDES  standard  that  is  useful  to  the 
industrial  community  has  forced  the  decision  to  define  PDES  as  a 
collection  of  versions.  Each  new  version  enhances  the  product 
data  definition  available  in  the  previous  version.  In  addition, 
each  new  version  will  expand  the  scope  of  PDES  to  incorporate 
more  life-cycle  activities.  As  these  versions  are  released,  the 
techniques  for  representing  the  conceptual  models  may  vary 
because  of  the  new  complexity  and  richness  of  the  specified 
information.  In  addition,  only  the  later  versions  will  specify 
sufficient  product  data  to  allow  database  and  knowledge  base 
implementations  to  be  efficiently  built. 

A conceptual  model  contains  the  fundamental  objects  and 
concepts  managed  by  an  enterprise.  The  conceptual  model  also 
depicts  the  relationships  among  the  fundamental  data  objects  of 
the  enterprise.  Fundamental  data  objects  are  combined  to  create 
useful  collections  of  data  which  are  subsets  of  the  conceptual 
model,  called  external  views.  An  "external  view"  consists  of 
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user-specific  data  and  the  structural  organization  of  that  data. 
The  procedures  for  creating  the  collections  are  unique  recipes  or 
instructions  for  manipulating  the  fundamental  data.  These 
procedures  require  management  in  their  own  right.  They  are  not 
part  of  the  conceptual  model.  The  rules  for  deriving  external 
views  are  user-specific  and  unique  to  each  application. 

Since  the  conceptual  model  includes  all  the  important  facts 
about  an  enterprise,  it  can  be  thought  of  as  a detailed 
"database"  containing  vital  constructs  which  can  be  extracted  and 
viewed  in  various  ways.  Extracts  can  provide  a mechanism  to 
validate  the  content  and  intent  of  the  conceptual  model. 

Once  the  first  sharable  topical  product  models  were 
generated  and  integrated,  the  PDES  group  had  to  consider  the 
following  technical  issue.  How  could  the  product  model  be 
represented  in  a totally  unambiguous  manner?  The  answer  was  to 
represent  the  information  using  a database  design  technique 
called  "data  modeling."  The  various  PDES  application 
subcommittees  then  implemented  the  specific  topical  data  model  in 
a variety  of  data  modeling  formats.  This  caused  a problem  at 
integration,  as  different  data  modeling  techniques  were  used  by 
different  application  subcommittees.  As  with  all  technologies, 
there  are  a range  of  tools,  each  of  which  is  best  for  solving 
specific  problems.  Improved  and  extended  data  modeling 
techniques,  as  well  as  the  tools  to  implement  them,  will  continue 
to  appear  in  the  future.  Because  PDES  will  be  an  ever  evolving 
standard,  it  is  appropriate  to  allow  the  different  topical  data 
models  to  be  defined  using  a variety  of  data  modeling  techniques. 

To  be  able  to  tolerate  and  integrate  multiple  modeling 
techniques,  a mechanism  is  needed  for  transferring  specific  data 
models  between  the  competing  data  modeling  techniques.  An  ideal 
candidate  for  this  mechanism  is  a "data  dictionary  system"  that 
can  save  the  product  data  model  in  a neutral  specification. 
Using  a data  dictionary  system  as  this  mechanism,  it  is  then 
necessary  to  implement  only  one  pair  of  translators  for  each  data 
modeling  technique.  This  allows  for  the  translation  of  one  data 
modeling  representation  into  the  neutral  format,  and  the 
translation  of  the  neutral  format  back  into  another  data  model 
representation.  The  data  dictionary  system  also  becomes  an 
effective  and  efficient  configuration  manager  for  the  development 
of  the  IPDM. 


PRODUCT  DATA  MANAGEMENT 

The  IPDM,  resulting  from  the  integration  of  the  merged 
topical  models,  abstractly  defines  the  way  in  which  the  product 
data  elements^  interrelate.  -In  addition, ^the  - "physical  level" 
defines  the  way  the  actual  product  data  is  represented,  organized 
and  stored  (such  as  on  a disk  or  in  memory) . [Figure  1]  The  PDES 
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community  is  currently  defining  levels  of  implementation  for 
PDES . These  levels  define  the  "road  map"  for  how  product  life- 
cycle  activities  (e.g.  design,  process  planning,  etc.)  will 
interface  to  the  PDES  implementation. 

This  leads  to  the  second  major  issue:  the  development  of  a 
mechanism  that  can  manage  the  enterprise  data  and  data  semantics 
for  use  in  PDES  implementations.  This  information  management 
capability  can  be  supported  by  a data  dictionary  system  that  has 
adequate  functionality.  The  data  dictionary  system  must  be  able 
to  interact  with  a variety  of  data  storage  techniques,  such  as 
relational  databases,  file  systems,  object  oriented  databases, 
etc.  The  data  dictionary  system  must  be  able  to  describe  the 
data  structures  (e.g.  strings,  numbers,  dates,  tables,  geometric 
entities)  that  exist  in  the  product  information  representation 
and  be  able  to  cross-reference  the  associations  among  these  data 
structures.  This  PDES  information  must  then  be  accessible  to  the 
life-cycle  systems  through  a neutral  language  that  may  be  depen- 
dent on  the  level  of  implementation  but  should  not  be  dependent 
on  the  actual  system  implementation  (i.e.,  the  language  of  a 
given  relational  database  management  system  (DBMS)  or  file 
management  system) . 


APPROACH 

The  storage  and  management  of  all  the  components  of  PDES 
development  information  in  one  logical,  standard,  data  dictionary 
system  is  the  cornerstone  for  automation  and  reusability  in  the 
future.  Such  a data  dictionary  system  is  required  to  manage  the 
numerous  PDES  topical  and  application  models,  model  integration, 
the  validation  process  and  the  necessary  documentation. 

The  Information  Resource  Dictionary  System  (IRDS)  standard 
being  developed  by  the  American  National  Standards  Institute 
(ANSI)  and  the  National  Institute  of  Standards  and  Technology 
(NIST)  can  meet  this  need.  The  IRDS  can  be  used  to  identify  and 
control  all  of  the  "pieces"  that  make  up  PDES  and  to  evaluate  the 
effect  of  needed  changes  that  will  occur  as  the  PDES  standard 
emerges.  With  the  use  of  the  extensibility  feature,  the  IRDS 
provides  a stable  platform  for  development  and  maintenance  even 
when  the  underlying  technology  is  changing.  [Figure  2] 

The  IRDS  can  support  system  integration  by  merging  develop- 
ment and  maintenance  tools  into  one  environment.  PDES  develop- 
ment requires  the  use  of  data  modeling  tools,  data  dictionaries, 
DBMS,  and,  eventually,  knowledge  base  systems  to  support  all  its 
functions.  Commercial  and  public-domain  products  exist  in  all 
these  areas.  They  can  be  easily  obtained,  but  not  easily 
interfaced.  The  IRDS*  can  provide  the  mechanism  by **which  these 
tools  can  be  interfaced  and  replaced  as  new  technologies  emerge. 


4 


The  IRDS  can  support  the  3 -schema  architecture  (i.e.,  the 
external  view  of  the  user,  the  logical  conceptual  model,  and  the 
physical  or  implementation  view  of  the  internal  model) . [Figure 
3]  Another  way  to  visualize  the  three-schema  architecture  is  as 
a 3-dimensional  space,  with  the  three  axes  representing  use, 
processing  and  universality.  Each  of  the  three  schemas — 
external,  internal  and  conceptual  — can  be  represented  as  a 
point  in  this  space.  The  major  component  of  each  of  the  schema 
points  projects  on  a different  axis:  external  projects  on  the  use 
axis,  internal  projects  on  the  processing  axis,  and  conceptual 
projects  on  the  universality  axis. 

This  architecture  permits  the  relationships  between  levels 
to  be  independently  defined,  permitting  some  changes  to  be  made 
to  the  specifications  at  one  level  without  affecting  the  speci- 
fications at  the  other  levels.  Major  changes,  such  as  expansion 
of  scope,  discovery  of  additional  relationships,  etc.,  will 
impact  all  levels.  Therefore,  it  is  important  to  know  how  each 
level  is  with  the  other  through  cross-referencing  relationships. 
The  IRDS  is  the  only  recognized  information  management  standard 
in  this  area. 

The  IRDS  provides  a basic  Functional  Schema  which  directly 
supports  much  of  the  information  that  an  organization  needs  to 
keep  about  implemented  software  systems.  For  example,  the 
ability  to  describe  the  data  elements  that  make  up  a record  and 
how  records  are  organized  into  a file  is  part  of  the  IRDS  BAsic 
Functional  Schema.  Further,  the  IRDS  provides  a general  schema 
extensibility  mechanism  for  tailoring  and  adding  types  of 
information  resources  that  need  to  be  managed  within  an 
organization.  Schema  extensibility  is  provided  since  the  IRDS 
does  not  intend  to  describe  all  of  the  types  of  resources  that 
enterprises  may  need  to  manage  with  a data  dictionary.  What  is 
provided  by  the  standard  is  a schema  with  a minimum  set  of 
information  resource  types,  to  be  used  as  an  example,  along  with 
building  blocks  for  extending  the  schema  to  meet  each 
organization's  needs.  It  is  this  extensibility  feature  which 
makes  the  use  of  IRDS  so  attractive. 

What  are  the  major  categories  of  product  data  information 
resources  that  must  be  managed  if  the  full  potential  of  an 
information  resource  dictionary  is  to  be  realized  for  PDES?  PDES 
information  resources  can  be  grouped  into  three  categories: 

1)  implemented  systems  and  data  organizations, 

2)  conceptual  models  and  business  rules,  and 

3)  data  usage  and  external  views  of  data. 

If  the  data  types  provided  by  the  IRDS  Basic  Functional 
Schema  are  examined,  most  of  -them  fall  within  - the^fdr st  category 
of  information  resources.  The  IGES/PDES  Organization  has  spent 
almost  all  its  effort  defining  the  second  category  of  resource 
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types.  Major  efforts  are  still  needed  in  the  third  category  to 
define  industry  and  activity  specific  views  of  PDES  or  applica- 
tion protocols. 

To  be  a more  complete  and  effective  tool  for  the  PDES 
community,  the  IRDS  schema  structures  must  be  modeled  with  an 
Information  Resource  Dictionary  (IRD)  to  store  and  access  the 
conceptual  IPDM.  The  schema  of  this  IRD  must  be  extended  to 
capture  and  document  the  meaning  of  the  entities,  relationships 
and  attributes  which  comprise  the  integrated  conceptual  model. 

Once  a neutral  conceptual  model  is  developed,  the  IRDS  can 
be  used  to  effect  change  control  over  existing  applications  and 
databases.  Currently,  IRDS  provides  facilities  for  recording, 
storing,  and  processing  descriptions  of  data.  It  can  create  and 
store  schemas  for  all  types  of  data  management  systems.  Thus, 
application  programs  will  not  need  to  incorporate  the  schemas 
into  their  code;  programs  can  obtain  the  necessary  information 
from  the  IRDS,  resulting  in  a true  data-driven  system.  The  PDES 
dictionary  can  also  serve  as  the  access  control  point  for  all 
current  models.  The  activities  described  below  provide  direc- 
tions to  pursue  to  support  specific  PDES  needs.  We  are  not 
attempting  to  address  more  general  problems. 


ACTIVITIES 

1.  Build  a schema  for  a PDES  Information  Resource  Dictionary, 
using  the  IRDS  schema  extensibility  feature  to  support  the 
storage  and  management  of  the  diverse  conceptual  models  built  by 
the  PDES  committees. 

The  extensibility  feature  of  IRDS  will  be  used  to  define  a 
set  of  information  resource  types,  called  metatypes,  which 
correspond  to  each  of  the  fundamental  constructs  found  within 
the  conceptual  modeling  techniques  used  by  PDES.  This  new 
schema  definition  will  allow  IRDS  to  support  the  storage  and 
retrieval  of  conceptual  models.  Automatic  dictionary  loading 
and  version-controlled  updates  must  be  added  to  the  existing 
IRDS  prototype  to  support  management  of  the  conceptual 
models . 

2 . Extend  the  PDES  Information  Resource  Dictionary  schema  to 
support  a full  three-schema  architecture,  and  populate  the  IRD 
with  PDES  information. 

Initially  this  repository  will  hold  the  conceptual  models, 
supporting  entity  definitions,  and  scoping  statements,  as 
well  as  related,  but  unresolved,  issues.  The  IRDS  Basic 
Functional  Schema  supports  only  information  * describing  the 
internal  schema,  specifically  physical  databases  and  files, 
computer  hardware,  and  user  profiles.  Therefore,  the  PDES 
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IRD  schema  will  be  expanded  to  support  a full  three  schema 
dictionary.  When  application  subsets,  testing  criteria,  test 
cases,  and  implementation  guidelines  are  developed,  the  PDES 
dictionary  can  then  be  populated  with  relevant  information. 
This  will  permit  evaluation  of  the  effects  of  changes  and 
expansions  in  the  PDES  standard.  These  resources  can  then  be 
brought  into  alignment  with  the  standard. 

3.  Develop  automated  or  assisted  translation  between  diverse 

data  models  and  represent  these  data  models  in  the  IRDS . 

There  are  three  types  of  data  models  being  produced  by  PDES 
activities.  PDES  Version  I will  contain  both  EXPRESS  and 

IDEF1X,  two  types  of  data  models.  In  addition,  some 

committees  are  formalizing  their  work  in  NIAM,  a third  type. 
A NIAM  model  must  be  translated  into  both  IDEF1X  and  EXPRESS 
before  it  can  be  incorporated  into  the  PDES  standard. 
Equivalent  concepts  between  these  models  must  therefore  be 
identified  and  formally  represented  to  ensure  that  the 

different  types  -are  consistent.  Translating  these  data 

models  into  the  IRDS  can  provide  PDES  with  a unified 

representation  of  this  information,  and  permit  consistency 
checking  among  the  data  models. 

4.  Interface  the  PDES  Information  Resource  Dictionary  to 

available  software. 

The  IRDS  provides  for  integration  between  data  modeling 
tools,  database  and  system  design  aids,  and  application 
development.  As  the  repository  for  dictionary  metadata 
describing  functions,  data,  and  objects  that  compose  an 

application,  the  IRDS  becomes  the  key  integration  tool  for 
PDES  application  development.  In  addition,  it  provides  the 
IRDS  Export/Import  Facility  to  control  moving  IRD  schema  and 
metadata  definitions  from  one  site  to  another.  The  IRDS 
Export/Import  Facility  is  currently  under  development  at 
NIST. 

4.1  Utilize  conceptual  modeling  tools. 

These  tools  are  used  in  the  requirements  analysis  and  system 
design  phases.  They  provide  quality  controls  in  the 
definition  of  both  data  models  and  functional  design.  Most 
will  also  generate  a prototype  database  schema  in  one  or  more 
relational  data  definition  languages.  Most  also  have  an 
interchange  form.  This  interchange  form  is  the  most  likely 
method  for  interfacing  these  tools  to  the  IRDS.  No 
standardization  efforts  are  active  within  ANSI  to  develop  a 
standard  conceptual  modeling  language  that  could  be  used  for 
this  purpose. 
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4.2  Support  IRDS  information  interchange  with  DBMS. 

DBMS  provide  a general  purpose  capability  for  storing, 
accessing,  and  managing  actual  instances  of  data.  The 
Structured  Query  Language  (SQL)  standard  and  the  Network 
Database  Language  (NDL)  standard  are  expected  to  be  the  first 
of  the  DBMS  related  standards  to  be  interfaced  to  the  IRDS 
standard.  Remote  Data  Access  (RDA) , an  International 
Organization  for  Standardization  (ISO)  standards  effort,  is 
not  yet  mature  enough  for  an  interface  to  IRDS  to  be 
designed.  RDA  also  supports  less  capability  than  a 
distributed  PDES  database  implementation  needs.  However,  ISO 
has  done  enough  work  in  the  distributed  area  to  identify  the 
minimum  information  requirements  that  a data  dictionary/di- 
rectory must  manage  to  support  this  distributed  aspect.  The 
IRDS  Service  Interface,  which  is  currently  under  review,  is 
an  addendum  to  the  IRDS  standard  that  will  support  the  use  of 
the  IRDS  in  an  active  mode.  The  Services  Interface  is 
expected  to  be  formally  accepted  as  part  of  the  IRDS  standard 
in  1990-91. 

5.  Develop  Relationships  to  Physical  Design. 

The  PDES  organization  is  not  heavily  concerned  with  how  PDES 
is  physically  implemented  because  many  of  these  issues  fall 
under  the  domain  of  implementors.  There  are  aspects  of 
physical  design,  however,  that  must  be  managed  to  maintain 
consistent  versions  of  PDES;  PDES  will  produce  an  exchange 
format  and  testing  suites  which  must  conform  to  the 
conceptual  models  defined  in  the  standard.  Therefore  the 
elements  of  the  conceptual  models  must  be  associated  with 
those  of  the  exchange  format  and  testing  libraries.  Further, 
there  must  be  an  ability  to  document  the  decisions  made  in 
the  physical  design  of  these  modules  and  to  detect  changes 
required  to  keep  these  modules  consistent  with  newer  versions 
of  PDES.  These  types  of  cross-referencing  information  can  be 
captured  and  stored  in  the  IRDS. 
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GLOSSARY 


Application  Model 

A data  model  which  addresses  the  information  requirements 
for  a specific  industry  or  vital  - business  - objective  such  as 
electrical  design  or  structural  analysis. 

Conceptual  Model 

An  abstraction  of  the  real  world  that  conveys  the  concepts, 
meaning  and  semantics  of  information  for  an  organization.  It 
forms  the  basis  for  a dialogue  between  systems  and  users  and  is 
based  on  a common  understanding  of  the  information  it  represents. 

Data  Attributes 

Properties  of  product  data  which  describe  the  data  objects. 
Data  Dictionary 

A repository  for  data  definitions,  system  documentation, 
data  representations,  and  requirements  descriptions  of 
information  managed  within  the  automated  or  manual  systems  of  an 
organization.  This  resource  is  then  available  over  the  life- 
cycle  of  developing  and  existing  systems. 

Enterprise 

May  be  a corporation,  a unit  or  division  of  a corporation, 
government  unit,  or  group  of  cooperating  organizations,  etc., 
which  is  the  source  or  owner  of  information. 

External  View 

That  set  of  information  which  is  sufficient  to  support  the 
performance  of  a particular  function  or  business  objective. 

Fundamental  Constructs 

Defines  the  basic  constructs  used  to  create  the  data  model. 
Each  data  model  technique  will  have  a set  of  primitive  elements 
that  are  used  to  formally  describe  an  actual  data  model. 

Heterogeneity 

Use  of  dissimilar  computer  hardware  and  software  in  support 
of  a common  objective. 
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Implementation  Model 

A design  of  the  data  organization  for  a system.  For  database 
systems  this  would  be  a database  schema  in  the  definition 
language  of  the  database  management  system  selected  to  implement 
the  system.  For-  applications,  this  would  be * the  data  structures 
in  the  computer  language  used  to  write  the  application  and  for 
object  oriented  systems,  this  would  be  the  object  class 
definitions . 

Integration 

The  process  of  merging  together  independently  developed 
models  into  a cohesive  and  consistent  model  which  reflects  a 
common  understanding  of  information  resources  used  within  an 
enterprise. 

IRD  Data  Layer 

The  layer  of  the  information  resource  dictionary  that 
manages  the  actual  descriptions  of  information  resources. 

IRD-IRD  Interface  Facility 

A method  of  exchanging  information  resource  dictionaries  to 
additional  sites  which  may  have  processing  responsibilities. 

IRD  Schema  Description  Layer 

Provides  the  basic  framework  on  which  to  build  the  types  of 
information  resources  to  be  managed  within  an  information 
resource  dictionary. 

IRD  Schema  Layer 

Defines  the  types  of  information  resources  to  be  managed 
within  an  information  resource  dictionary;  these  are  called 
metatypes . 

IRDS 

The  Information  Resource  Dictionary  Standard  is  a draft 
proposed  ANSI  and  FIPS  data  dictionary  standard. 

Knowledge  Base 

A system  which  is  capable  of  persistent  data  management  and 
can  actively  enforce  the  business  rules  defined  against  the  data. 
A knowledge  base  is  capable  of  evaluating  requested  functions  and 
performing  constraint  checking  on  the  data.  - — • ■ i 
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Level  I Implementation 

A passive  file  interchange  implementation  of  PDES. 

Level  II  Implementation 

An  active  file  interchange  implementation  of  PDES. 

Level  III  Implementation 

A database  implementation  of  PDES. 

Level  IV  Implementation 

A knowledge  base  implementation  of  PDES. 

Life-Cycle 

The  distinct  phases  into  which  every  system  may  be  divided 
such  as  requirements,  design,  implementation,  production,  and 
maintenance.  Each  phase  may  require  different  support  from  the 
data  dictionary  which  is  used  to  administrate  it. 

NDL 


The  Network  Database  Language  is  the  ANSI  standard  for  data 
definition  and  access  for  network  databases. 

Physical  Design 

The  process  of  evaluating  an  implementation  model  or  design 
and  factoring  in  performance  characteristics  and  data  access  to 
optimize  the  design. 

PDES 


Product  Data  Exchange  Specification  is  a developing  standard 
which  will  provide  for  the  unambiguous  interchange  of  life  cycle 
product  data  from  concept,  to  engineering  design,  to  manufacture, 
and  to  support. 

RDA 


The  Remote  Data  Access  protocol  is  an  ISO  standards  activity 
which  is  developing  a standard  for  distributed  system  access. 

SQL 


The  Structured  Query  Language  is  the  ANSI  standard  data 
definition  and  access  for  relational  databases. 
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Topical  Model 


A data  model  which  incorporates  the  requirements  of  many 
users  into  a data  model  of  limited  scope.  The  scope  defines  the 
topic  of  the  data  model  (e.g.  geometry  data  model) . 
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